Skip to content

Conversation

@mathiasgrimm
Copy link
Contributor

Memory Limit Behavior Change for Queue Workers

Current Behavior

When running Laravel queue workers with --memory=0:

php artisan queue:listen --memory=0
php artisan queue:work --memory=0

The worker currently exits with static::EXIT_MEMORY_LIMIT after processing each job, regardless of the actual memory usage. The only exceptions are when:

  • The connection is lost
  • A SIGQUIT signal is received

Issue

The current implementation treats 0 as a special value that forces worker termination, but this behavior is inconsistent with how zero values are handled in other parts of the Worker class. Here are the relevant examples:

// Illuminate\Queue\Worker::daemon:180
if ($options->rest > 0) {
    $this->sleep($options->rest);
}

// Illuminate\Queue\Worker::pauseWorker:289
$this->sleep($options->sleep > 0 ? $options->sleep : 1);

// Illuminate\Queue\Worker::markJobAsFailedIfWillExceedMaxAttempts:550
if (! $job->retryUntil() && $maxTries > 0 && $job->attempts() >= $maxTries) {
    $this->failJob($job, $e);
}

In all these cases, zero is treated as a way to disable the feature rather than trigger special behavior.

Proposed Change

We should modify the memory limit check to align with other worker options' behavior. When --memory=0 is specified, it should disable memory limit checking entirely instead of forcing worker termination after each job.

This change would:

  1. Make the behavior more intuitive and consistent with other worker options
  2. Allow for true continuous processing when memory limits aren't needed
  3. Maintain the ability to set specific memory limits when required

Implementation Notes

The change would involve modifying how zero values are interpreted in the memory limit checks, similar to how other worker options handle zero values:

// Proposed behavior:
public function memoryExceeded($memoryLimit)
{
    return $memoryLimit > 0 && (memory_get_usage(true) / 1024 / 1024) >= $memoryLimit;
}

Backward Compatibility

This is a breaking change as it modifies existing behavior. It should be:

  1. Documented clearly in the release notes
  2. Included in a major version release
  3. Accompanied by clear migration instructions for users who rely on the current behavior

@mathiasgrimm mathiasgrimm changed the title [12.x] feat: --memory=0 should mean infinite memory [12.x] feat: --memory=0 should mean skip memory exceeded verification Jan 29, 2025
@mathiasgrimm mathiasgrimm changed the title [12.x] feat: --memory=0 should mean skip memory exceeded verification [12.x] feat: --memory=0 should mean skip memory exceeded verification (Breaking Change) Jan 29, 2025
@taylorotwell taylorotwell merged commit d112023 into master Feb 5, 2025
28 checks passed
@taylorotwell taylorotwell deleted the feat-queue-unlimited-memory branch February 5, 2025 11:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants